🧹 Nitpick | 🔵 Trivial

Consider also asserting the full diagnostic message.

The companion test invalid-constant-pointer-taking.slang shows the compiler emits two diagnostic lines at &: the short name address-of operator not supported and the full message the '&' operator for taking addresses is no longer supported in Slang. The CHECK here only verifies the short form, so a regression where the full user-facing message is dropped or altered would not be caught. A second CHECK line would lock that in.

     // CHECK: error[E30087]: address-of operator not supported
+    // CHECK: the '&' operator for taking addresses is no longer supported in Slang
     float* p = &buffer[threadId.x];

⚠️ Potential issue | 🟡 Minor

Original test intent for & paths is no longer exercised.

The file header comment states the test exists to verify that Slang does not allow taking a pointer from StructuredBuffer/RWStructuredBuffer. With the new E30087 short-circuit on &, the mutablePtr1 (Line 14) and ptr1 (Line 25) cases now fail at operator resolution before the buffer-pointer semantics are ever checked — the previous mutability / l-value diagnostics on these lines are gone. The equivalent __getAddress cases (Lines 18, 29) still validate the original intent, so coverage is preserved there, but the & cases here are now effectively redundant with the new address-of-operator-unsupported.slang test.

Consider either (a) dropping the & cases from this file since the dedicated test already covers E30087, or (b) replacing them with __getAddress variants that still exercise the buffer-pointer rejection, to keep this file focused on its original purpose.

Also applies to: 25-27

🔴 Bug: Unconditional E30087 will break existing tests that expect E30019

This check fires unconditionally for every operator& invocation and returns CreateErrorExpr(invoke) before the parameter validation loop. This preempts all downstream diagnostics — including E30019 (pointer type mismatch) — because the error expression propagates ErrorType through subsequent assignments, causing later type checks to short-circuit.

Two existing tests use & for address-of and expect E30019 errors that will now never be emitted:

1. tests/language-feature/dynamic-dispatch/ptr-to-interface-local.slang — IFoo* p = &local; expects CHECK: error[E30019]. With this change, E30087 fires first and E30019 is never reached. Test will fail.

2. tests/language-feature/dynamic-dispatch/diagnose-ptr-to-interface-implicit-cast.slang — Lines 39 (&f), 55 (&b), 59 (&ib) all use & for address-of. The test expects E30019 on subsequent conversion lines (44, 49, 54, 62), but since the & expressions now return ErrorType, the conversion checks that produce E30019 won't trigger.

Suggested fix: Update both test files to expect E30087 on the & lines and either remove or adjust the E30019 expectations accordingly. For diagnose-ptr-to-interface-implicit-cast.slang, consider splitting address-of tests from pointer-conversion tests so conversion diagnostics can be validated independently (e.g., construct Foo* via __getAddress instead of &).

🟡 Gap: Error message lacks migration guidance and user-facing docs need updating

The message tells users that & is no longer supported but doesn't suggest a replacement. The PR description says "Internal code uses __getAddress instead," and the parser does register __getAddress as a syntax keyword. Users encountering this error won't know how to fix their code.

Additionally, the user guide at docs/user-guide/03-convenience-features.md (lines 546–598, "Pointers (limited)" section) explicitly shows & operator usage for obtaining pointers:

• Line 558: MyType* pNext2 = &pNext[1];
• Line 576: return test(&obj); // !! ERROR !!
• Line 592: "Slang can produce pointers using the & operator from data in global memory."

These docs become incorrect with this change and should be updated.

Suggestion: If __getAddress is the intended user-facing replacement, update the message to mention it:

span { loc = "expr:Expr", message = "the '&' operator for taking addresses is no longer supported in Slang; use '__getAddress(expr)' instead" }

If __getAddress is internal-only (the __ prefix suggests this), consider what the user migration path is and document it in the user guide.

🟡 Gap: Test only covers SPIRV target with one basic pattern

Since the error is emitted at the semantic checker level (target-independent), the -target spirv flag here is not strictly necessary. More importantly, the test only covers &buffer[threadId.x] (global buffer element access). Given this is a breaking change, additional coverage would strengthen confidence:

• &localVar — local variable address-of (previously valid on CPU/CUDA targets)
• &structInstance.member — struct member access
• & in generic function bodies — ensure deprecation fires during specialization
• A positive test showing __getAddress(...) still works as the replacement

Suggestion: Consider removing the target flag (since the error is target-independent) or adding a second test variant for -cpu to confirm the error is consistent across backends.